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The Benefits of Using Explicit Congestion Notification (ECN) 
Abstract 


The goal of this document is to describe the potential benefits of 
applications using a transport that enables Explicit Congestion 
Notification (ECN). The document outlines the principal gains in 
terms of increased throughput, reduced delay, and other benefits when 
ECN is used over a network path that includes equipment that supports 
Congestion Experienced (CE) marking. It also discusses challenges 
for successful deployment of ECN. It does not propose new algorithms 
to use ECN nor does it describe the details of implementation of ECN 
in endpoint devices (Internet hosts), routers, or other network 
devices. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc8087. 
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Introduction 


Internet transports (such as TCP and Stream Control Transmission 
Protocol (SCTP)) are implemented in endpoints (Internet hosts) and 
are designed to detect and react to network congestion. Congestion 
may be detected by loss of an IP packet or, if Explicit Congestion 
Notification (ECN) [RFC3168] is enabled, by the reception of a packet 
with a Congestion Experienced (CE) marking in the IP header. Both of 
these are treated by transports as indications of congestion. ECN 
may also be enabled by other transports: UDP applications that 
provide congestion control may enable ECN when they are able to 
correctly process the ECN signals [RFC8085] (e.g., ECN with RTP 
[RFC6679]). 


Active Queue Management (AQM) [RFC7567] is a class of techniques that 
can be used by network devices (a router, middlebox, or other device 
that forwards packets through the network) to manage the size of 
queues in network buffers. 


A network device that does not support AQM typically uses a drop-tail 
policy to drop excess IP packets when its queue becomes full. The 
discard of packets is treated by transport protocols as a signal that 
indicates congestion on the end-to-end network path. End-to-end 
transports, such as TCP, can cause a low level of loss while seeking 
to share capacity with other flows. Although losses are not always 
due to congestion (loss may be due to link corruption, receiver 
overrun, etc.), endpoints have to conservatively presume that all 
loss is potentially due to congestion and reduce their rate. 

Observed loss therefore results in a congestion control reaction by 
the transport to reduce the maximum rate permitted by the sending 
endpoint. 


ECN makes it possible for the network to signal the presence of 
incipient congestion without incurring packet loss; it lets the 
network deliver some packets to an application that would otherwise 
have been dropped if the application or transport did not support 
ECN. This packet-loss reduction is the most obvious benefit of ECN, 
but it is often relatively modest. However, enabling ECN can also 
result in a number of beneficial side effects, some of which may be 
much more significant than the immediate packet-loss reduction from 
receiving a CE marking instead of dropping packets. Several benefits 
reduce latency (e.g., reduced head-of-line blocking). 


The use of ECN is indicated in the ECN field [RFC3168], which is 
carried in the packet header of all IPv4 and IPv6 packets. This 
field may be set to one of the four values shown in Figure 1. The 
Not-ECT codepoint ’00’ indicates a packet that is not using ECN. The 
ECT(0) codepoint ’01’ and the ECT(1) codepoint ’10’ both indicate 
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that the transport protocol using the IP layer supports the use of 
ECN. The CE codepoint ’11’ is set by an ECN-capable network device 
to indicate congestion to the transport endpoint. 


4+----- 4+----- 4+--------- + 
| ECN FIELD | Name | 
4+----- 4+----- 4+--------- + 
| o | 0 | Not-EcT | 
| 0 | 1 | ECT (1) | 
1 0 ECT (0) 
| ıı | 1 |Œ | 
+----- 4+----- 4+--------- + 


Figure 1: The ECN Field in the IP Packet Header (based on [RFC3168]) 


When an application uses a transport that enables use of ECN 
[RFC3168], the transport layer sets the ECT(0) or ECT(1) codepoint in 
the IP header of packets that it sends. This indicates to network 
devices that they may mark, rather than drop, the ECN-capable IP 
packets. An ECN-capable network device can then signal incipient 
congestion (network queuing) at a point before a transport 
experiences congestion loss or high queuing delay. The marking is 
generally performed as the result of various AQM algorithms [RFC7567] 
where the exact combination of AQM/ECN algorithms does not need to be 
known by the transport endpoints. 


The focus of the document is on usage of ECN by transport- and 
application-layer flows, not its implementation in endpoint hosts, 
routers, and other network devices. 

1.1. Terminology 
The following terms are used: 


AQM: Active Queue Management. 


CE: Congestion Experienced; a codepoint value ’11’ marked in the ECN 
field of the IP packet header. 


ECN-capable IP Packet: A packet where the ECN field is set to a non- 
zero ECN value (i.e., with ECT(0), ECT(1), or the CE codepoint). 


ECN-capable network device: An ECN-capable network device may 


forward, drop, or queue an ECN-capable packet and may choose to CE 
mark this packet when there is incipient congestion. 
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ECN-capable transport/application: A transport that sends ECN-capable 
IP Packets, monitors reception of the ECN field, and generates 
appropriate feedback to control the rate of the sending endpoint to 
provide end-to-end congestion control. 


ECN field: A 2-bit field specified for use with explicit congestion 
Signaling in the IPv4 and IPv6 packet headers. 


Endpoint: An Internet host that terminates a transport protocol 
connection across an Internet path. 


Incipient Congestion: The detection of congestion when it is 
starting, perhaps by a network device noting that the arrival rate 
exceeds the forwarding rate. 


Network device: A router, middlebox, or other device that forwards IP 
packets through the network. 


non-ECN-capable: A network device or endpoint that does not interpret 
the ECN field. Such a device is not permitted to change the ECN 
codepoint. 


not-ECN-capable IP Packet: An IP packet with the ECN field set to a 
value of zero (’00’). A not-ECN-capable packet may be forwarded, 
dropped, or queued by a network device. 


2. Benefit of Using ECN to Avoid Congestion Loss 


An ECN-capable network device is expected to CE mark an ECN-capable 
IP packet as a CE when an AQM method detects incipient congestion 
rather than drop the packet [RFC7567]. An application can benefit 
from this marking in several ways, which are detailed in the rest of 
this section. 


2.1. Improved Throughput 


ECN seeks to avoid the inefficiency of dropping data that has already 
made it across at least part of the network path. 


ECN can improve the throughput of an application, although this 
increase in throughput is often not the most significant gain. When 
an application uses a lightly to moderately loaded network path, the 
number of packets that are dropped due to congestion is small. Using 
an example from Table 1 of [RFC3649], for a standard TCP sender with 
an RTT of 0.1 seconds, a packet size of 1500 bytes, and an average 
throughput of 1 Mbps, the average packet-drop ratio would be 0.02 
(i.e., 1 in 50 packets). This translates into an approximate 2% 
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throughput gain if ECN is enabled. (Note that in heavy congestion, 
packet loss may be unavoidable with or without ECN.) 


2.2. Reduced Head-of-Line Blocking 


Many Internet transports provide in-order delivery of received data 
segments to the applications they support. For these applications, 
use of ECN can reduce the delay that can result when these 
applications experience packet loss. 


Packet loss may occur for various reasons. One cause arises when an 
AQM scheme drops a packet as a signal of incipient congestion. 
Whatever the cause of loss, a missing packet needs to trigger a 
congestion control response. A reliable transport also triggers 
retransmission to recover the lost data. For a transport providing 
in-order delivery, this requires that the transport receiver stall 
(or wait) for all data that was sent ahead of a lost segment to be 
correctly received before it can forward any later data to the 
application. A loss therefore creates a delay of at least one RTT 
after a loss event before data can be delivered to an application. 
We call this head-of-line blocking. This is the usual requirement 
for TCP and SCTP. Partially Reliable SCTP (PR-SCTP) [RFC3758], UDP 
[RFC768] [RFC8085], and the Datagram Congestion Control Protocol 
(DCCP) [RFC4340] provide a transport that does not provide 
reordering. 


By enabling ECN, a transport continues to receive in-order data when 
there is incipient congestion and can pass this data to the receiving 
application. Use of ECN avoids the additional reordering delay ina 
reliable transport. The sender still needs to make an appropriate 
congestion response to reduce the maximum transmission rate for 
future traffic, which usually will require a reduction in the sending 
rate [RFC8085]. 


2.3. Reduced Probability of RTO Expiry 


Some patterns of packet loss can result in a Retransmission Timeout 
(RTO), which causes a sudden and significant change in the allowed 
rate at which a transport/application can forward packets. Because 
ECN provides an alternative to drop for network devices to signal 
incipient congestion, this can reduce the probability of loss and 
hence reduce the likelihood of RTO expiry. 


Internet transports/applications generally use an RTO timer as a last 
resort to detect and recover loss [RFC8085] [RFC5681]. Specifically, 
an RTO timer detects loss of a packet that is not followed by other 
packets, such as at the end of a burst of data segments or when an 
application becomes idle (either because the application has no 
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further data to send or the network prevents sending further data, 
e.g., flow or congestion control at the transport layer). This loss 
of the last segment (or last few segments) of a traffic burst is also 
known as a "tail loss". Standard transport recovery methods, such as 
Fast Recovery [RFC5681], are often unable to recover from a tail 
loss. This is because the endpoint receiver is unaware that the lost 
segments were actually sent and therefore generates no feedback 
[Fla13]. Retransmission of these segments relies on expiry of a 
transport retransmission timer. This timer is also used to detect a 
lack of forwarding along a path. Expiry of the RTO results in the 
consequent loss of state about the network path being used. This 
typically includes resetting path estimates such as the RTT, 
reinitializing the congestion window, and possibly making updates to 
other transport state. This can reduce the performance of the 
transport until it again adapts to the path. 


An ECN-capable network device cannot eliminate the possibility of 
tail loss because a drop may occur due to a traffic burst exceeding 
the instantaneous available capacity of a network buffer or as a 
result of the AQM algorithm (e.g., overload protection mechanisms 
[RFC7567]). However, an ECN-capable network device that observes 
incipient congestion may be expected to buffer the IP packets of an 
ECN-capable flow and set a CE mark in one or more packet(s) rather 
than triggering packet drop. Setting a CE mark signals incipient 
congestion without forcing the transport/application to enter 
retransmission timeout. This reduces application-level latency and 
can improve the throughput for applications that send intermittent 
bursts of data. 


The benefit of avoiding retransmission loss is expected to be 
significant when ECN is used on TCP SYN/ACK packets [RFC5562] where 
the RTO interval may be large because TCP cannot base the timeout 
period on prior RTT measurements from the same connection. 


2.4. Applications That Do Not Retransmit Lost Packets 


A transport that enables ECN can receive timely congestion signals 
without the need to retransmit packets each time it receives a 
congestion signal. 


Some latency-critical applications do not retransmit lost packets, 
yet they may be able to adjust their sending rate following detection 
of incipient congestion. Examples of such applications include UDP- 
based services that carry Voice over IP (VoIP), interactive video, or 
real-time data. The performance of many such applications degrades 
rapidly with increasing packet loss, and the transport/application 
may therefore employ mechanisms (e.g., packet forward error 
correction, data duplication, or media codec error concealment) to 
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mitigate the immediate effect of congestion loss on the application. 
Some mechanisms consume additional network capacity, some require 
additional processing, and some contribute additional path latency 
when congestion is experienced. By decoupling congestion control 
from loss, ECN can allow transports that support these applications 
to reduce their rate before the application experiences loss from 
congestion. This can reduce the negative impact of triggering loss- 
hiding mechanisms with a direct positive impact on the quality 
experienced by the users of these applications. 


2.5. Making Incipient Congestion Visible 


A characteristic of using ECN is that it exposes the presence of 
congestion on a network path to the transport and network layers, 
thus allowing information to be collected about the presence of 
incipient congestion. 


Recording the presence of CE-marked packets can provide information 
about the current congestion level experienced on a network path. A 
network flow that only experiences CE marking and no loss implies 
that the sending endpoint is experiencing only congestion. A network 
flow may also experience loss (e.g., due to queue overflow, AQM 
methods that protect other flows, link corruption, or loss in 


middleboxes). When a mixture of CE marking and packet loss is 
experienced, transports and measurements need to assume there is 
congestion [RFC7567]. Therefore, an absence of CE marks does not 


indicate a path has not experienced congestion. 


The reception of CE-marked packets can be used to monitor the level 
of congestion by a transport/application or a network operator. For 
example, ECN measurements are used by Congestion Exposure (ConEx) 
[RFC6789]. In contrast, metering packet loss is harder. 


2.6. Opportunities for New Transport Mechanisms 


ECN can enable design and deployment of new algorithms in network 
devices and Internet transports. Internet transports need to regard 
both loss and CE marking as an indication of congestion. However, 
while the amount of feedback provided by drop ought naturally be 
minimized, this is not the case for ECN. In contrast, an ECN-capable 
network device could provide richer (more frequent and fine-grained) 
indication of its congestion state to the transport. 


For any ECN-capable transport (ECT), the receiving endpoint needs to 
provide feedback to the transport sender to indicate that CE marks 

have been received. [RFC3168] provides one method that signals once 
each round-trip time (RTT) that CE-marked packets have been received. 
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A receiving endpoint may provide more detailed feedback to the 
congestion controller at the sender (e.g., describing the set of 
received ECN codepoints or indicating each received CE-marked 
packet). Precise feedback about the number of CE marks encountered 
is supported by RTP when used over UDP [RFC6679] and has been 
proposed for SCTP [ST14] and TCP [ECN-FEEDBACK] . 


More detailed feedback is expected to enable evolution of transport 
protocols allowing the congestion control mechanism to make a more 
appropriate decision on how to react to congestion. Designers of 
transport protocols need to consider not only how network devices 
CE-mark packets but also how the control loop in the application/ 
transport reacts to reception of these CE-marked packets. 


Benefit has been noted when packets are CE marked early using an 
instantaneous queue, and if the receiving endpoint provides feedback 
about the number of packet marks encountered, an improved sender 
behavior has been shown to be possible, e.g, Data Center TCP (DCTCP) 
[AL10]. DCTCP is targeted at controlled environments such as a data 
center. This is a work in progress, and it is currently unknown 
whether or how such behavior could be safely introduced into the 
Internet. Any update to an Internet transport protocol requires 
careful consideration of the robustness of the behavior when working 
with endpoints or network devices that were not designed for the new 
congestion reaction. 


3. Network Support for ECN 


For an application to use ECN requires that the endpoints enable ECN 
within the transport being used. It also requires that all network 
devices along the path at least forward IP packets that set a 
non-zero ECN codepoint. 


ECN can be deployed both in the general Internet and in controlled 


environments: 

o ECN can be incrementally deployed in the general Internet. The 
IETF has provided guidance on configuration and usage in 
[RFC7567]. 


o ECN may be deployed within a controlled environment, for example, 
within a data center or within a well-managed private network. 
This use of ECN may be tuned to the specific use case. An example 
is DCTCP [AL10] [DCTCP]. 
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Early experience of using ECN across the general Internet encountered 
a number of operational difficulties when the network path either 
failed to transfer ECN-capable packets or inappropriately changed the 
ECN codepoints [BA11]. A recent survey reported a growing support 
for network paths to pass ECN codepoints [TR15]. 


The remainder of this section identifies what is needed for network 
devices to effectively support ECN. 


3.1. The ECN Field 


The current IPv4 and IPv6 specifications assign usage of 2 bits in 
the IP header to carry the ECN codepoint. This 2-bit field was 
reserved in [RFC2474] and assigned in [RFC3168]. 


[RFC4774] discusses some of the issues in defining alternate 
semantics for the ECN field and specifies requirements for a safe 
coexistence in an Internet that could include routers that do not 
understand the defined alternate semantics. 


Some network devices were configured to use a routing hash that 
included the set of 8 bits forming the now deprecated Type of Service 
(TOS) field [RFC1349]. The present use of this field assigns 2 of 
these bits to carry the ECN field. This is incompatible with use in 
a routing hash because it could lead to IP packets that carry a CE 
mark being routed over a different path to those packets that carried 
an ECT mark. The resultant reordering would impact the performance 
of transport protocols (such as TCP or SCTP) and UDP-based 
applications that are sensitive to reordering. A network device that 
conforms to this older specification needs to be updated to the 
current specifications [RFC2474] to support ECN. Configuration of 
network devices must note that the ECN field may be updated by any 
ECN-capable network device along a path. 


3.2. Forwarding ECN-Capable IP Packets 


Not all network devices along a path need to be ECN-capable (i.e., 
perform CE marking). However, all network devices need to be 
configured not to drop packets solely because the ECT(0) or ECT(1) 
codepoints are used. 


Any network device that does not perform CE marking of an ECN-capable 
packet can be expected to drop these packets under congestion. 
Applications that experience congestion at these network devices do 
not see any benefit from enabling ECN. However, they may see benefit 
if the congestion were to occur within a network device that did 
support ECN. 


Fairhurst & Welzl Informational [Page 10] 


RFC 8087 Benefits of ECN March 2017 


3.3. Enabling ECN in Network Devices 


Network devices should use an AQM algorithm that CE-marks ECN-capable 
traffic when making decisions about the response to congestion 
[RFC7567]. An ECN method should set a CE mark on ECN-capable packets 
in the presence of incipient congestion. A CE-marked packet will be 
interpreted as an indication of incipient congestion by the transport 
endpoints. 


There is an opportunity to design an AQM method for an ECN-capable 
network device that differs from an AQM method designed to drop 
packets. [RFC7567] states that the network device should allow this 
behavior to be configurable. 


[RFC3168] describes a method in which a network device sets the CE 
mark at the time that the network device would otherwise have dropped 
the packet. While it has often been assumed that network devices 
should CE-mark packets at the same level of congestion at which they 
would otherwise have dropped them, [RFC7567] recommends that network 
devices allow independent configuration of the settings for AQM 
dropping and ECN marking. Such separate configuration of the drop 
and mark policies is supported in some network devices. 


3.4. Coexistence of ECN and Non-ECN Flows 


Network devices need to be able to forward all IP flows and provide 
appropriate treatment for both ECN and non-ECN traffic. 


The design considerations for an AQM scheme supporting ECN needs to 
consider the impact of queueing during incipient congestion. For 
example, a simple AQM scheme could choose to queue ECN-capable and 
non-ECN-capable flows in the same queue with an ECN scheme that 
CE-marks packets during incipient congestion. The CE-marked packets 
that remain in the queue during congestion can continue to contribute 
to queueing delay. In contrast, non-ECN-capable packets would 
normally be dropped by an AQM scheme under incipient congestion. 
This difference in queueing is one motivation for consideration of 
more advanced AQM schemes and may provide an incentive for enabling 
flow isolation using scheduling [RFC7567]. The IETF is defining 
methods to evaluate the suitability of AQM schemes for deployment in 
the general Internet [RFC7928]. 


3.5. Bleaching and Middlebox Requirements to Deploy ECN 
Network devices should not be configured to change the ECN codepoint 


in the packets that they forward, except to set the CE codepoint to 
signal incipient congestion. 
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Cases have been noted where an endpoint sends a packet with a 
non-zero ECN mark, but the packet is received by the remote endpoint 
with a zero ECN codepoint [TR15]. This could be a result of a policy 
that erases or "bleaches" the ECN codepoint values at a network edge 
(resetting the codepoint to zero). Bleaching may occur for various 
reasons (including normalizing packets to hide which equipment 
supports ECN). This policy prevents use of ECN by applications. 


When ECN-capable IP packets, marked as ECT(0) or ECT(1), are 
re-marked to non-ECN-capable (i.e., the ECN field is set to the zero 
codepoint), this could result in the packets being dropped by 
ECN-capable network devices further along the path. This eliminates 
the advantage of using of ECN. 


A network device must not change a packet with a CE mark to a zero 
codepoint; if the network device decides not to forward the packet 
with the CE mark, it has to instead drop the packet and not bleach 
the marking. This is because a CE-marked packet has already received 
ECN treatment in the network, and re-marking it would then hide the 
congestion signal from the receiving endpoint. This eliminates the 
benefits of ECN. It can also slow down the response to congestion 
compared to using AQM because the transport will only react if it 
later discovers congestion by some other mechanism. 


Prior to [RFC2474], a previous usage assigned the bits now forming 
the ECN field as a part of the now deprecated TOS field [RFC1349]. A 
network device that conforms to this older specification was allowed 
to re-mark or erase the ECN codepoints, and such equipment needs to 
be updated to the current specifications in order to support ECN. 


3.6. Tunneling ECN and the Use of ECN by Lower-Layer Networks 


Some networks may use ECN internally or tunnel ECN (e.g., for traffic 
engineering or security). These methods need to ensure that the ECN 
field of the tunnel packets is handled correctly at the ingress and 
egress of the tunnel. Guidance on the correct use of ECN is provided 
in [RFC6040]. 


Further guidance on the encapsulation and use of ECN by non-IP 
network devices is provided in [ECN-ENCAP]. 


4. Using ECN across the Internet 


A receiving endpoint needs to report the loss it experiences when it 

uses loss-based congestion control. So also, when ECN is enabled, a 

receiving endpoint must correctly report the presence of CE marks by 

providing a mechanism to feed this congestion information back to the 
sending endpoint [RFC3168] [RFC8085], thus enabling the sender to 
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react to experienced congestion. This mechanism needs to be designed 
to operate robustly across a wide range of Internet path 
characteristics. This section describes partial deployment, that is, 
how ECN-enabled endpoints can continue to work effectively over a 
path that experiences misbehaving network devices or when an endpoint 
does not correctly provide feedback of ECN information. 


4.1. Partial Deployment 


Use of ECN is negotiated between the endpoints prior to using the 
mechanism. 


ECN has been designed to allow incremental partial deployment 
[RFC3168]. Any network device can choose to use either ECN or some 
other loss-based policy to manage its traffic. Similarly, transport/ 
application negotiation allows sending and receiving endpoints to 
choose whether ECN will be used to manage congestion for a particular 
network flow. 


4.2. Detecting Whether a Path Really Supports ECN 


Internet transports and applications need to be robust to the variety 
and sometimes varying path characteristics that are encountered in 
the general Internet. They need to monitor correct forwarding of ECN 
over the entire path and duration of a session. 


To be robust, applications and transports need to be designed with 
the expectation of heterogeneous forwarding (e.g., where some IP 
packets are CE marked by one network device and some by another, 
possibly using a different AQM algorithm, or when a combination of CE 
marking and loss-based congestion indications are used). Note that 
[RFC7928] describes methodologies for evaluating AQM schemes. 


A transport/application also needs to be robust to path changes. A 
change in the set of network devices along a path could impact the 
ability to effectively signal or use ECN across the path, e.g., when 
a path changes to use a middlebox that bleaches ECN codepoints (see 
Section 3.5). 


A sending endpoint can check that any CE marks applied to packets 
received over the path are indeed delivered to the remote receiving 
endpoint and that appropriate feedback is provided. (This could be 
done by a sender setting a known CE codepoint for specific packets in 
a network flow and then checking whether the remote endpoint 


correctly reports these marks [ECN-FALLBACK] [TRI15].) If a sender 
detects persistent misuse of ECN, it needs to fall back to using 
loss-based recovery and congestion control. Guidance on a suitable 


transport reaction is provided in [ECN-FALLBACK]. 
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4.3. Detecting ECN-Receiver Feedback Cheating 


Appropriate feedback requires that the endpoint receiver not try to 
conceal reception of CE-marked packets in the ECN feedback 


information provided to the sending endpoint [RFC7567]. Designers of 
applications/transports are therefore encouraged to include 
mechanisms that can detect this misbehavior. If a sending endpoint 


detects that a receiver is not correctly providing this feedback, it 
needs to fall back to using loss-based recovery instead of ECN. 


5. Summary: Enabling ECN in Network Devices and Hosts 


This section summarizes the benefits of deploying and using ECN 
within the Internet. It also provides a list of prerequisites to 
achieve ECN deployment. 


Application developers should, where possible, use transports that 
enable ECN. Applications that directly use UDP need to provide 
support to implement the functions required for ECN [RFC8085]. Once 
enabled, an application that uses a transport that supports ECN will 
experience the benefits of ECN as network deployment starts to enable 
ECN. The application does not need to be rewritten to gain these 


benefits. Figure 2 summarizes the key benefits. 
4+--------- +--------------------- - -- - 5 = + 
| Section | Benefit | 
4+--------- +------------------------ - = $= + 
De. Improved Throughput 
22 Reduced Head-of-Line Blocking 
| 2.3 | Reduced Probability of RTO Expiry 
| 2.4 | Applications that do not Retransmit Lost Packets | 
| 2.5 | Making Incipient Congestion Visible 
| 2.6 | Opportunities for New Transport Mechanisms 
+--------- +------------------------ - = + 


Figure 2: Summary of Key Benefits 


Network operators and people configuring network devices should 
enable ECN [RFC7567]. 


Prerequisites for network devices (including IP routers) to enable 
use of ECN include: 


o A network device that updates the ECN field in IP packets must use 
IETF-specified methods (see Section 3.1). 


o A network device may support alternate ECN semantics (see 
Section 3.1). 
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o A network device must not choose a different network path solely 
because a packet carries a CE-codepoint set in the ECN Field; 
CE-marked packets need to follow the same path as packets with an 
ECT(0) or ECT(1) codepoint (see Section 3.1). Network devices 
need to be configured not to drop packets solely because the 
ECT(0) or ECT(1) codepoints are used (see Section 3.2). 


o An ECN-capable network device should correctly update the ECN 
codepoint of ECN-capable packets in the presence of incipient 
congestion (see Section 3.3). 


o Network devices need to be able to forward both ECN-capable and 
not-ECN-capable flows (see Section 3.4). 


o A network device must not change a packet with a CE mark to a not- 
ECN-capable codepoint (’00’); if the network device decides not to 
forward the packet with the CE mark, it has to instead drop the 
packet and not bleach the marking (see Section 3.5). 


Prerequisites for network endpoints to enable use of ECN include the 
following: 


o An application should use an Internet transport that can set and 
receive ECN marks (see Section 4). 


o An ECN-capable transport/application must return feedback 
indicating congestion to the sending endpoint and perform an 
appropriate congestion response (see Section 4). 


o An ECN-capable transport/application should detect paths where 
there is persistent misuse of ECN and fall back to not sending 
ECT(0) or ECT(1) (see Section 4.2). 


o Designers of applications/transports are encouraged to include 
mechanisms that can detect and react appropriately to misbehaving 
receivers that fail to report CE-marked packets (see Section 4.3). 


6. Security Considerations 
This document introduces no new security considerations. Each RFC 


listed in this document discusses the security considerations of the 
specification it contains. 
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